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Abstract 

Interface adaptation allows code written for one interface to be used 
with a software component with another interface. When multiple adapters 
are chained together to make certain adaptations possible, we need a way 
to analyze how well the adaptation is done in case there are more than one 
chains that can be used. We introduce an approach to precisely analyz- 
ing the loss in an interface adapter chain using a simple form of abstract 
interpretation. 

1 Introduction 

The computing world of today is becoming increasingly diverse. This includes 
a great increase in the number of services that are being developed that provide 
various functionality. It also includes an increase in the number of developers 
independently creating new interfaces to similar computing services. To avoid 
lock-in to a specific vendor, it would be ideal if code written to the interface of 
one service can be used without change when it needs to be used with another 
service. Unfortunately, this cannot be done directly without standardization 
of interfaces, and the slow speed of standardization processes coupled with the 
rapid proliferation of services precludes standardization in many cases. 

Interface adapters can provide a solution to this problem by transforming 
interfaces as necessary. And chaining them together enables much more flex- 
ibility without incurring a prohibitive development cost in creating all of the 
required interface adapters for direct interface adaptation. Unfortunately, an 
interface adapter is likely to be imperfect, so interface adaptation would often 
incur adaptation loss. This is even more of an issue when interface adapters 
are chained. To properly consider loss in the construction of interface adapter 
chains, a mathematical framework is required to analyze such chains. 

Previous work either took the approach of treating a method as a single 
unit that is either available or not available, or loosened this by treating the 
availability of a method probabilistically [3] . The former is unable to precisely 
analyze cases where individual methods cannot be precisely adapted, whereas 
the latter is a very rough approximation. This paper outlines another approach 
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to handling the partial adaptation of methods, which is to use a simple form 
of abstract interpretation [5j HI |H [6]. Dividing arguments up into abstract 
domains, the abstract interpretation approach looks at which abstract domains 
can be handled by a method instead of looking at the likelihood. Interface 
adapters are "executed abstractly" to derive which abstract domains can be 
handled by a method in the target interface. 

The paper is organized as follows. We look at related work in section [2j 
In section [3J we describe the mathematical framework with which to analyze 
loss in interface adapter chains using abstract interpretation. We discuss the 
computational complexity of the problem in section 3] and describe a greedy 
algorithm in section [5] Section [5] concludes. 

2 Related work 

Vayssiere [TB] supports the interface adaptation of proxy objects for Jini [TJ. 
The goal is to enable clients to use services even when they have different in- 
terfaces than expected. Adapters are registered with an adapter service, which 
in turn registers all acyclic chains of interface adapters that can adapt to a 
given type to the lookup service. Registering all possible chains can result in 
an exponential number of registrations in the lookup service (they claim that 
the maximum number of registrations would be limited, but they ignore that 
there can be an exponential number of paths in a reasonable graph). There is 
no discussion of which chain of adapters should be used to adapt an interface, 
simply specifying that all chains matching the expected input and output types 
should be returned. 

Gschwind )8| allows components to be accessed through a foreign interface 
and implements an interface adaptation system for Enterprise JavaBeans 
It implements a centralized adapter repository that stores adapters, along with 
weights that mark the priority of an adapter. Clients query an adaptation 
component to obtain an interface adapter chain, which is used to convert the 
interface of an object into another. The adaptation repository uses Dijkstra's 
algorithm [7] to construct the shortest interface adapter chain that adapts a 
source interface into a target interface. While there is support for marking an 
adapter as lossy or not, it does not have the capability to properly analyze and 
compare the loss of interface adapter chains. 

Ponnekanti and Fox |14) suggests using interface adapter chaining for net- 
work services to handle the different interfaces available for similar types of 
services. They provide a way to query all services whose interfaces can be 
adapted to a known interface. They also support lossy adapters, but the sup- 
port is limited to detecting whether a particular method and specific parameters 
can be handled at runtime. They do not provide a method to analyze the loss 
of an interface adapter chain, so they are unable to choose a chain with less loss 
when alternatives are available. Adapter chains are constructed through a rule 
system based on the source and target interfaces of adapters, which is similar 
to constructing a path in a graph through a blind search algorithm. They also 
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support the composition of services in addition to transforming a single interface 
to another, which is accomplished by constructing a tree of interface adapters. 

Kim et al. [TU] describes an ad hoc scheme for analyzing the loss in inter- 
face adapter chains. The scheme is based on boolean matrixes which specify 
the methods required in a source interface to implement a method in a target 
interface. A mapping product is defined on these matrixes which computes the 
loss incurred when interface adapters are chained. The mathematical model 
they use is not rigorously constructed, however. They also only consider the 
adaptation of methods as a whole and do not handle the case where methods 
could handle certain arguments but not others. 

3 Mathematical basics 

We can define an interface adapter graph, which is a directed graph where 
interfaces are nodes and adapters are edges. We also assume that a method 
accepts only a single argument: multiple arguments can be modeled as a tuple 
with multiple components |15j , while no argument can be modeled by a dummy 
argument. 

For each method in an interface, its argument domain is divided up into 
disjoint domains that are each represented by abstract values. For example, 
integer arguments could be mapped to abstract values c?+, <i_, and do. These 
domains and abstract values must be fixed for each method in an interface, 
and they must not be different for different interface adapters. The chaining of 
interface adapters cannot be analyzed otherwise. 

There is a special abstract value denoted by _L distinct from any other ab- 
stract value, which is used when a method is unable to handle any other abstract 
value, i.e. when a method cannot handle any arguments. Including _L in the set 
of all possible abstract values for a method can be considered lifting the set [12] , 
and we call this lifted set the abstract argument domain for the method. 

3.1 Method dependencies 

To represent how methods in a source interface are used to implement a method 
in a target interface, including which arguments must be used for the methods 
in the source interface to handle an argument for the method in the target 
interface, we use a function-based approach. Functions are represented with a 
set-theoretic approach |13j , where a function is a set of pairs of arguments and 
values. 

Let there be an interface adapter A with source interface Is and target 
interface It- Let Di be the abstract argument domain of method i in Is, and 
let D'j be the abstract argument domain of method j in It- If Is has n methods 
and It has n' methods, then we can define the abstract dependency function Ha 
for A: 

h A : Di x D 2 x • • • x D n -> 2 D ' 1 x 2 D * x • • • x 2 D '^' 
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where the jth component in a result tuple is the set of all possible abstract 
values that can be handled by method j in the target interface given the specified 
abstract values accepted by the methods in the source interface. If a method 
is unavailable in the source interface or it is unable to handle any arguments, 
then its corresponding abstract value in the argument to Ha would be _L. All 
components in the result tuple include _L so that chained interface adapters can 
be analyzed even when certain methods end up being unavailable. 

We also define a method availability vector p for the abstract interpretation 
approach. It is simply a tuple of sets with type 2 Dl x 2 D ' 2 x • • • x 2 Dn , assuming 
there are n methods and Di is the abstract argument domain for method i. 
It represents the abstract values that each method is able to handle, and it is 
not intrinsic to an interface or interface adapter. Instead, it expresses how well 
interface adaptation is done. 

In the following, we will use the shorthand U for the "union" of two tuples, 
in which the result is a tuple with the same number of components, and each 
component is the union of the corresponding components in the arguments. In 
other words, [Si, . . . , S n ] U [Si, . . . , S' n ] = [Si U S(, . . . , S„ U S' n ]. The "indexed 
union" of tuples is a straightforward extension of the shorthand. We will also 
denote the Cartesian product of the components of a tuple of sets with the 
prefix x . In other words, x [Si, . . . , S n ] = Si X • • • X S n . 

If an interface adapter A with abstract dependency function \ia were to be 
used to convert an source interface Is to target interface It, where the method 
availability vector for Is is p, then it is easy to see that each component of the 
resulting method availability vector q should be: 

q = |J h A (x) (1) 

Basically, each component of q should be the union of all possible abstract values 
for the corresponding method as adapted from p through Ha- 

It would be more convenient to simply apply a function to a method avail- 
ability vector, and this can easily be done by defining an abstract adaptation 
function Ja corresponding to an abstract dependency function Ha based on 
equation (fTJ, where _D 1; D n are the abstract argument domains for the 
source interface of the adapter: 

f A = {(X, J h A (x)) | X C D x x ■ ■ ■ x D n } (2) 

xex 

Obviously, constructing an abstract dependency function for an interface 
adapter is easier than constructing an abstract adaptation function, so it would 
be expected that the abstract dependency function is constructed first, and 
then the abstract adaptation function is constructed from this, after which the 
abstract adaptation function would be used to analyze interface adapter chains. 
We will denote the abstract adaptation function of an interface adapter A by 
depend(A). 
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Now that we have defined the abstract adaptation function, defining the 
adaptation operator is simple: it is simply function application. In fact, we will 
not use special notation to represent the operator and will just use the standard 
notation: 

Ia(p) 

Unlike in previous work which used a single value to denote the availability 
of a method [3J [3] , there is no need to define something like a dummy method 
since an adaptation dependency function is general enough to encompass cases 
which are ambiguous in the other approaches. If a method in a target interface 
can always be implemented, then the appropriate abstract value results can 
be specified for an argument of [JL, . . . , _L], whereas if a method can never be 
implemented, then [{J-}, . . . , {^}] can be returned as the result. 

Wc denote a method availability vector for an interface I to a fully functional 
service by 1/, where each set in the tuple includes the entire abstract argument 
domain for the corresponding method. 

3.2 Adapter composition 

We would like to be able to derive a composite abstract adaptation function 
from the composition of two abstract adaptation functions, which would be 
equivalent to describing the chaining of two interface adapters as if they were a 
single interface adapter. 

For the abstract interpretation approach, this is very straightforward because 
the abstract adaptation function is a function: the composition is just function 
composition. And function composition is well known to be associative |17j . 
although not commutative in general. In fact, we will use the standard notation 
for abstract adaptation function composition: 

!a< ° /a 

We can also show a monotonicity property, which formalizes the notion that 
extending an interface adapter chain results in worse adaptation loss. If A% 
and A2 are interface adapters, where A\ converts 1\ to I2 and A2 converts I2 
to I3, with /a ± — depend(Ai) and Ja 2 — depend (A2) , and Ha 1 and Ha 2 are 
the adaptation dependency functions associated with Ja x and /a 2 , respectively, 
then: 

Ia 2 (z)= [J hA 2 (x) C (J h A . 2 (x) = f A2 (li 2 ) 

ie(xz) xG(xlj 2 ) 

.-. (/^o/^Ki/Jc/^^) (3) 

with the shorthand that the "subset" relationship for tuples denotes each cor- 
responding component satisfying the subset relationship, i.e. [Si,...,S n ] C 
[S[, . . . , S' n ] denotes Si C S[ A ■ ■ • A S n C S' n . 

The definitions of the abstract adaptation function, the abstract dependency 
function, and the method availability vector in section 13. H along with the as- 
sociativity and monotonicity rules proven in this section, provide a succinct 
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Figure 1: Interface adapter graph example. 



way to mathematically express the chaining of lossy interface adapters using an 
abstract interpretation approach. 

3.3 An example 

As an example, we apply the abstract interpretation approach to the interfaces 
and adapters in figure [1] The abstract argument domains for each method in 
each interface must be determined manually based on a human-level understad- 
ing of the interfaces, not only considering a natural division of arguments but 
also anticipating divisions relevant to potential interface adapters. Table [T] con- 
tains an example of how the abstract argument domains could be defined for 
figure [U 

For interface adapter Video ltoVideo2, the playAudio method in Videol is 
not required to implement any of the methods, while stop, skip, and caption 
methods in Video2 cannot be implemented using the methods of Videol. Let 
us say that playVideo of Videol can handle MOV files, which can contain video 
encoded in MP4, AVI files, which can contain video encoded in INDEO and 
DIVX, and MKV files, which can contain video encoded in MP4, DIVX, and 
THEORA. Then we would have an abstract dependency function with tuples as 
specified in table [2] The abstract dependency function has 16 elements, while 
the abstract adaptation function has 2 4 x 2 4 = 256 elements, which we do not 
show here. 

From the adaptation dependency function in table [2j it is easy to see that 
with the interface adapter Video ltoVideo2, an argument for play in Video2 that 
corresponds to abstract value MP4 can be handled if playVideo in Videol can 
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Interface Method Abstract values 



Video 1 


play Video 
playAudio 


MOV, AVI, MKV 
MP3, OGG, WAV 


Video2 


play 
stop 
skip 
caption 


INDEO, MP4, THEORA, DIVX 

DUMMY 

INTEGER 

LANGUAGE 


Video3 


play 

getVolume 
setVolume 
setEqualizer 


MOV, AVI, MKV, RM 
DUMMY 
INTEGER 
EQSPEC 



play AU, WAV, OGG 

adjustAudio VOLUME, EQUALIZER, MIXED 



Table 1: Example abstract argument domains for figure [TJ 



((±,±),({±},{L},{±},{±})) 
((L,MP3),({±},{±},{±},{±})) 
((!_, OGG, ({!.}, {L}, {!_}, {-L})) 
((±,WAV),({±},{±},{±},{±})) 
((MOV,±),({±,MP4},{±},{±},{±})) 
((MOV, MP3), ({J., MP4}, {!_}, {±}, {!_})) 
((MOV, OGG), ({!_, MP4}, {J.}, {J.}, {J.})) 
((MOV, WAV), ({_L, MP4}, {±}, {L}, {J.})) 
((AVI, J.), ({_L, INDEO, DIVX}, {J.}, {J.}, {J.})) 
((AVI, MP3), ({_L, INDEO, DIVX}, {±}, {!}, {J.})) 
((AVI, OGG), ({_L, INDEO, DIVX}, {±}, {J_}, {J.})) 
((AVI, WAV), ({_L, INDEO, DIVX}, {J.}, {J.}, {J.})) 
((MKV, ±), ({±, MP4, DIVX, THEORA}, {_L}, {J.}, {J.})) 
((MKV, MP3), ({±, MP4, DIVX, THEORA}, {_L}, {_L}, {_L})) 
((MKV, OGG), ({±, MP4, DIVX, THEORA}, {_L}, {!}, {_L})) 
((MKV, WAV), ({!_, MP4, DIVX, THEORA}, {_L}, {_L}, {_L})) 



Table 2: Elements in an example abstract dependency function. 
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handle an argument that corresponds to abstract values MOV or MKV. If / 
is the corresponding abstract adaptation function and the method availability 
vector isp= [{J_, MOV, MKV}, {_L, MP3}], then 

f(p) = [{_L, MP4, DIVX, THEORA}, {_!_}, {±}, {J.}] 

which shows that with interface adaptation to Video2, play would be able to 
handle arguments corresponding to MP4, DIVX, and THEORA, while the stop, 
skip, and caption methods would not be available. 

For the other interface adapters, the adapters Video 2to Video 3, VideoSto- 
Audio, and Video3toVideol have 40 elements in their abstract dependency 
functions and 2048 elements in their abstract adaptation functions, while the 
adapters Videolto Audio and AudiotoVideoS have 16 elements in their abstract 
dependency functions and 256 elements in their abstract adaptation functions. 

4 Complexity 

The abstract interpretation approach can easily encompass the discrete ap- 
proach [2] by having each method accept only a single abstract value besides 
J_. However, this does not mean that the optimal adapter chaining problem, 
where the number of accepted abstract values is maximized, is NP-complctc. 
The reason is that the reduction of a method dependency matrix in the dis- 
crete approach to an abstract adaptation function in the abstract interpretation 
approach can require exponential time. In fact, simply storing the abstract 
adaptation function can require an exponential amount of memory. 

In the discrete and probabilistic approaches [2j |3], representing a method 
dependency matrix or a probabilistic adaptation factor requires 0(m 2 ) space, 
where m is the maximum number of methods in an interface. Applying the adap- 
tation or composition operators would require 0(m 2 ) or 0(m 3 ) time. However, 
since the abstract interpretation approach requires that functions be represented 
as a set of tuples to retain generality, it requires 0(d m ) space to represent an 
abstract dependency function and 0(2 dm ) space to represent an abstract adap- 
tation function. Recall that an abstract argument domain must include _L in 
addition to a separate abstract value, so d is necessarily greater than or equal 
to 2, thus this is a truly exponential bound. 

In fact, the exponential space complexity is a lower bound, not just an upper 
bound. With exactly m methods in a source interface and with d\, c^, ■ ■ ■ , d m 
abstract values in the abstract argument domains for each method, the number 
of tuples in the abstract dependency function is exactly YiiLi <^i> an d the number 
of tuples in the abstract adaptation function is exactly YJ4L1 2 di ■ We can see 
this in the example of section 13.31 

With complex interfaces that have many methods and non-trivial abstract 
argument domains, the exponential space complexity of the abstract interpreta- 
tion approach makes it unlikely to be used in a system not dedicated to analyz- 
ing lossy interface chains which lacks the correspondingly exponential amount 
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of memory. It is an open question whether real world interfaces will be triv- 
ial enough such that the abstract interpretation approach can be used more 
generally. 

5 A greedy algorithm 

While the exponential complexity of the abstract interpretation approach might 
make it unfeasible to obtain an optimal adapter chain on demand in a resource- 
constrained interactive system and virtually impossible to analyze complex in- 
terface adapters, it may be a slow but useful tool for software architecture anal- 
ysis to derive an optimal adapter chain with simple interface adapters. So we 
describe an algorithm which can construct an optimal interface adapter chain in 
algorithm [TJ which works thanks to the monotonicity property in equation ([3]). 



Algorithm 1 Adapter chaining algorithm with abstract interpretation, 
procedure Prob-Greedy-Chain(G = (V,E), s, t) 

C ■(— { [] } > chains to extend 

M — > discarded chains 

D {[] ^ Idim(i r )} > method dependency matrixes 

while C ^ do 

c <- element of C maximizing Count-Abstract(c, D) 
if c 7^ [] A source(c[l)) = s then 
return c 

else if no acyclic chain not in C U M extends c then 

C <- C- {c} 

M^IU {c} 
else 

if c = [] then 

B <- {[e] | e G E, target(e) = t} 

else 

B <— {e : c | e G E, target(e) = source(c[l])} 
end if 

remove cyclic chains from B 
C ^CUB 

D<-flU{e:c4 D[c] o depend(e) | e : c G B} 
end if 
end while 
end procedure 



Algorithm [T] can be extended to support behavior similar to service discovery 
by checking whether the current source is among a potential set of source inter- 
faces instead of just checking against one can be similarly extended. Abstract 
values that represent arguments can also be similarly weighted to prioritize what 
needs to be adapted. 
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Algorithm 2 Computing number of accepted abstract values, 
function Count- Abstract(c, D) 
s «— source(c[l]) 
v<-D[c](l„) 

return sum of count of abstract values in each component of v 
end function 



6 Conclusions 

When many similar software components from different developers need to be 
used interchangeably due to various reasons such as having to work with di- 
verse software environments or an evolving software architecture, using inter- 
face adapters is a way to reuse existing software components without having to 
rewrite them. Chaining interface adapters allows much more interface adapta- 
tion with fewer resources having to be devoted to actually developing interface 
adapters. However, insurmountable incompatibilities between interfaces of sim- 
ilar software components may force interface adapters to be less than perfect, 
so an approach to analyze the loss incurred by chains of interface adapters is 
needed. 

The abstract interpretation approach can be the most precise way to ana- 
lyze the loss in chains of interface adapters, not having to rely on questionable 
assumptions about the partial adaptation of methods. However, it does rely on 
abstract argument domains being properly defined for every method in every in- 
terface. An improperly set up abstract argument domain would require a great 
deal of effort to update related data structures appropriately, and sometimes it 
might not be easy to define an abstract argument domain which would work 
well with every conceivable interface and interface adapter. 

A much more serious problem with the abstract interpretation approach is 
its complexity. It has exponential space complexity, which means a prohibitive 
amount of memory may be required. Even worse, it requires exponential effort 
to set up the necessary values, which for even moderately complex interface 
adapters might be infeasible to do automatically by computer, much less by 
a human developer. And the necessary functions have to be constructed by a 
human developer unless sophisticated program analyses can be developed that 
could automatically define abstract argument domains and infer how interface 
adapter code will adapt them. 

The exponential complexity of the abstract interpretation approach suggests 
that it should be used for offline analysis of simple interface adapter chains. The 
better precision may be useful when determining if a set of interface adapters 
shipped with a deployment of a ubiquitous computing environment can satis- 
factorily support seamless operation. However, the abstract interpretation ap- 
proach may still be practical as a subsystem if the number of methods and the 
size of abstract argument domains are small: it is an open question of whether 
they would be small enough in real world systems. 

These limitations suggest future avenues for research. One direction would 
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be to take advantage of the semantics of a software component to automate the 
setup of abstract argument domains as much as possible. Another is the study of 
alternative formulations for expressing abstract argument domains besides sets 
or specialized adaptation functions applicable to a wide range of software inter- 
faces, which could allow polynomial complexity for analyzing loss in interface 
adapter chains using abstract interpretation. 
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